%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%  Copyright by Collin Howland, Faith Letzkus, and Julio Trujillo  %%
%%  at Washington University in St. Louis. 			    %%
%%  This work is licensed under the Creative Commons                %%
%%  Attribution-NonCommercial-ShareAlike 5.0 International License. %%
%%  To view a copy of this license, visit                           %%
%%  http://creativecommons.org/licenses/by-nc-sa/4.0/.              %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newcommand{\commonfolder}{../../common-files}
\newcommand{\webcommon}{../Web_Common}

\input{\commonfolder/header}

\lhead{\bfseries SEED Labs -- Clickjacking Lab}

\begin{document}

\begin{center}
{\LARGE Clickjacking}
\end{center}

\vspace{0.1in}
\fbox{\parbox{6in}{\small Copyright \copyright\ 2021 \ \ by Collin
      Howland, Faith Letzkus, Julio Trujillo, and Steve Cole at  
      Washington University in St.\ Louis.  \\
      This work is licensed under a Creative Commons
      Attribution-NonCommercial-ShareAlike 4.0 International License. 
      If you remix, transform, or build upon the material, 
      this copyright notice must be left intact, or reproduced in a way
      that is reasonable to the medium in which the work is being 
      re-published.}}
\vspace{0.1in}

% *******************************************
% Overview
% ******************************************* 
\section{Overview}

Clickjacking, also known as a ``UI redress attack,'' is an attack that
tricks a user into clicking on something they do not intend to when
visiting a webpage, thus ``hijacking'' the click. In this lab, we will
explore a common attack vector for clickjacking: the attacker creates a
webpage that loads the content of a legitimate page but overlays one or
more of its buttons with invisible button(s) that trigger malicious
actions.  When a user attempts to click on the legitimate page's
buttons, the browser registers a click on the invisible button instead,
triggering the malicious action.

\paragraph{Example scenario.} Suppose an attacker acquires the domain
``starbux.com'' and creates a website with that URL. The site first
loads the legitimate target website ``starbucks.com'' in an iframe
element spanning the entire webpage, so that the
malicious``starbux.com'' website looks identical to the legitimate
``starbucks.com'' website.  The attacker's site then places an invisible
button on top of the `Menu' button on the displayed ``starbucks'' page;
the button triggers a 1-click purchase of the attacker's product on
Amazon.  If the user is logged on to Amazon when they try to click the
legitimate button, the inadvertent click on the invisible button will
make the unintended purchase without the user's knowledge or consent.

\paragraph{Topic coverage.} This lab covers the following topics:
\begin{itemize}[noitemsep]
 \item Clickjacking attack
 \item Countermeasures: Frame busting and HTTP headers
 \item iframes and sandboxes
 \item JavaScript
\end{itemize}

\paragraph{Lab environment.}
\seedenvironmentB
\nodependency



% *******************************************
% Lab Environment Setup
% *******************************************j
\section{Lab Environment Setup}

In this lab, we will use two websites.  The first is the vulnerable
homepage of the fictional business ``Alice's Cupcakes'', accessible at
\url{www.cjlab.com}.  The second is the attacker's malicious web site
that is used for hijacking clicks intended for the Alice's Cupcakes
page, accessible at \url{www.cjlab-attacker.com}. We
use containers to set up the web servers.
 
% ------------------------------------------- SUBSECTION
% -------------------------------------------
\subsection{Container Setup and Commands}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{\commonfolder/container/setup}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Websites}

We use two containers, one running the website for Alice's Cupcakes (the
``defender'', with IP address \texttt{10.9.0.5}) , and the other running
the website for the attacker (with IP address \texttt{10.9.0.105}).  The
IP addresses for these two containers must be consistent in the
\texttt{docker-compose.yml} file and the \texttt{/etc/hosts} file (see
below), and we recommend not changing them from their default values.

\paragraph{The Defender container.}
The website for Alice's Cupcakes is hosted on an Apache web server.  The
website setup is included in \texttt{apache\_defender.conf} inside the
defender image folder.  The configuration specifies the URL for the
website and the folder where the web application code is stored.  The
configuration also contains placeholders for HTTP response headers
returned by the server (commented out), which will be filled in during
the course of the lab as a defense countermeasure.

\begin{lstlisting}
<VirtualHost *:80>
     DocumentRoot /var/www/defender
     ServerName www.cjlab.com
#    Header set <Header-name> "<value>";
#    Header set Content-Security-Policy " \
#             <directive> '<value>'; \
#           "
</VirtualHost>
\end{lstlisting}

Because we need to modify the defender's web page inside this container,
for convenience as well as to allow the modified files to persist beyond
the containers, we have mounted a folder (\texttt{Labsetup/defender} on
the hosting VM) to the container's \texttt{/var/www/defender} folder,
which is the \texttt{DocumentRoot} folder in our Apache configuration.
Therefore any files we modify inside the \texttt{defender} folder on the
VM will be seen as modified by the defender's web server on the
container. 

\paragraph{The Attacker container.}
The attacker's website is also hosted on an Apache web server.  The
website setup is included in \texttt{apache\_attacker.conf} inside the
attacker image folder.  The Apache configuration for this website is
as follows:

\begin{lstlisting}
<VirtualHost *:80>
    ServerName www.cjlab-attacker.com
    DocumentRoot "/var/www/attacker"
    DirectoryIndex attacker.html
</VirtualHost>
\end{lstlisting}
 
Because we need to modify the attacker's web page inside this container,
for convenience as well as to allow the modified files to persist beyond
the containers, we have mounted a folder (\texttt{Labsetup/attacker} on
the hosting VM) to the container's \texttt{/var/www/attacker} folder,
which is the \texttt{DocumentRoot} folder in our Apache configuration.
Therefore any files we modify inside the \texttt{attacker} folder on the
VM will be seen as modified by the attacker's web server on the
container. 

\paragraph{Important note.} Any time you make updates to the websites,
you may need to clear the browser's cache and/or rebuild and restart the
containers for the change to be visible, depending on the scope of the
change.

\paragraph{DNS configuration.}
We access the defender website and the attacker website using their
respective URLs.  To enable these hostnames to be mapped to their
corresponding IP addresses, we need to add the following entries to the
\texttt{/etc/hosts} file on the VM.  You need to use the root privilege
to change this file (using \texttt{sudo}).

\begin{lstlisting}
10.9.0.5        www.cjlab.com
10.9.0.105      www.cjlab-attacker.com
\end{lstlisting}


\paragraph{Test: defender.} Build and start the containers, then
navigate to the page \url{http://www.cjlab.com} on the VM.  You should
see a page for Alice's Cupcakes, a fictional local bakery. If the whole
site does not fit in your window, use \texttt{Ctrl + (minus key)} and
\texttt{Ctrl + (plus key)} to zoom out and in respectively until the
site fits.  Note that the header and footer buttons on the site are just
placeholders and do not contain live links.

\paragraph{Test: attacker.}
Next, navigate to the page \url{http://www.cjlab-attacker.com}.  You
should see a single button which, when clicked, takes you to a page that
tells you you've been hacked, but in reality could perform a variety of
malicious actions.  

The goal of the attacker is to overlay this button onto a view of the
defender's webpage displayed on the attacker's site, so that a victim
user will inadvertently click the malicious button when they think they
are clicking a button on the defender's webpage.


% *******************************************
% Lab Tasks
% *******************************************
\section{Lab Tasks} 

%%%%%%%%%% Task 1 %%%%%%%%%% 

\subsection{Task 1: Copy that site!}

In the \texttt{defender} folder, you will find the files comprising the
website for Alice's Cupcakes: \texttt{index.html} and
\texttt{defender.css}.  In the \texttt{attacker} folder, you will find
the files comprising the attacker's website: \texttt{attacker.html} and
\texttt{attacker.css}.  You will be making changes to all of these files
except \texttt{defender.css} throughout the lab. 

Our first step as the attacker is to add code to \texttt{attacker.html}
so that it mimics the Alice's Cupcakes website as closely as possible.
A common way to do this is with an HTML Inline Frame element
(``iframe''). An iframe enables embedding one HTML page within another.
The \texttt{src} attribute of the iframe specifies the site to be
embedded, and when the iframe code is executed on a page, the embedded
site is loaded into the iframe. 

\paragraph{Embed the defender's site into the attacker's site.}
\begin{itemize}
    \item Add an iframe HTML element in \texttt{attacker.html} that 
    pulls from \texttt{http://www.cjlab.com}. 
    \item Modify the CSS in \texttt{attacker.css} using the height,
    width, and position attributes to make the iframe cover the whole 
    page and make the button overlay the iframe.
    
    \item Hints:
    \begin{itemize}
       \item Explicitly set the iframe to have no border.
       \item Investigate the `absolute' and `relative' settings of the 
       position attribute to determine which should be used.
    \end{itemize} 

    \item Test your changes by navigating to the attacker's website.
          (Remember that you may need to clear the browser's cache and
          reload the page to see changes made after the initial load.)

\end{itemize} 

\paragraph{Question:}
\begin{enumerate}
    \item With the iframe inserted, what does the attacker's website
    look like?
\end{enumerate}

%%%%%%%%%% Task 2 %%%%%%%%%% 

\subsection{Task 2: Let’s Get Clickjacking!}

\paragraph{Basic clickjacking attack.}
Add to the given CSS code for a ``button'' object in
\texttt{attacker.css} to make the malicious button in
\texttt{attacker.html} invisible. Position the button such that it
covers the ``Explore Menu'' button within the iframe added in the
previous Task. There are a variety of strategies for doing this; we
recommend investigating these CSS attributes: \texttt{margin-left},
\texttt{margin-top}, \texttt{color}, and \texttt{background-color}. When
this task is complete, you will have a functioning clickjacking attack. 

\paragraph{Questions:}
\begin{enumerate}
\setcounter{enumi}{1}
    \item How does the attacker's site’s appearance compare to that of
	  the defender's site?

    \item What happens when you try to click on the ``Explore Menu'' button?

    \item Describe a scenario where clickjacking of the type just
    demonstrated could occur and lead to undesirable consequences for 
    the user.
\end{enumerate}


%%%%%%%%%% Task 3 %%%%%%%%%% 

\subsection{Task 3: Bust That Frame!}
``Frame busting'' is the practice of writing scripts to prevent a web
page from being displayed within a frame.  One way to do this is by
including script code in a website that prevents the site from being
framed -- that is, prevents another site from opening it in an iframe.
The technique we will implement today checks that the site to be
protected is the topmost site on any page where it is being displayed,
thus preventing buttons on an attacker's page from being overlaid on top
of it. 

\paragraph{Write the frame busting script.} 

Open the file \texttt{defender/index.html}, which contains code for the
Alice's Cupcakes homepage, which we would like to protect from
clickjacking. Here, you will fill in the Javascript method called
$makeThisFrameOnTop()$. Your code should compare \texttt{window.top} and
\texttt{window.self} to find out if the top window and the current
site's window are the same object (as they should be). If not, use the
\href{https://developer.mozilla.org/en-US/docs/Web/API/Location}{Location
Object} to set the location of the top window to be the same as the
location of the current site's window. This should be a simple method
and take no more than a few lines of code. Test it out and confirm that
your script successfully stops the clickjacker. 

\paragraph{Reminder.} Remember that any time you make changes to one of
the websites, you may need to clear the browser's cache and reload the
page for the changes to take effect.

\paragraph{Questions:}
\begin{enumerate}
\setcounter{enumi}{4}
    \item What happens when you try navigating to the attacker's site
          now?

    \item What happens when you try clicking the button?
\end{enumerate}


%%%%%%%%%% Task 4 %%%%%%%%%% 

\subsection{Task 4: Attacker Countermeasure (Bust the Buster)}

\paragraph{Disable the frame-busting script.}
Now let's explore how simple it is for the attacker to create a
workaround for front-end clickjacking defenses like frame busting. There
are multiple ways of accomplishing this, such as with a double frame
attack, but one of the simplest in the current scenario is to add the
``sandbox'' attribute to the malicious iframe. Read more about the
sandbox attribute on
\underline{\href{https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe}{this
page}} about iframes, then add the ``sandbox'' attribute to the iframe
in \texttt{attacker.html} and answer the following questions.  


\paragraph{Questions:}
\begin{enumerate}
\setcounter{enumi}{6}
    \item What does the sandbox attribute do? 
          Why does this prevent the frame buster from working?

    \item What happens when you navigate to the attacker's site after
          updating the iframe to use the `sandbox' attribute?

    \item What happens when you try clicking the button?
\end{enumerate}


%%%%%%%%%% Task 5 %%%%%%%%%% 

\subsection{Task 5: The Ultimate Bust}
As we saw in Task 4, front-end defenses are not sufficient to prevent
clickjacking, because front-end defenses such as frame busting can be
directly circumvented by other front-end settings on the attacker's
webpage. To prevent clickjacking attacks more comprehensively, we need
to set up back-end (i.e.\ server-side) defenses.

Server-side defenses can prevent front-end attacks such as the ones
presented in this lab so far, which rely on an attacker's website being
able to fetch the benign website's content before the benign site has a
chance to execute any front-end defenses. 

Specifically, by providing a special HTTP header in response to a
request for the content of a legitimate website, the site can instruct
browsers to only display the content according to specific matching
rules designed to exclude clickjacking attack scenarios.

One header used for this purpose is called ``X-Frame-Options,'' and its
value specifies the conditions under which the requested content will be
displayed.  This header is not part of the official HTTP specification
but is processed by many common browsers.

Another more standardized header that can provide protection against
clickjacking is the ``Content-Security-Policy'' header, which can
specify a diverse set of directives as part of a site's Content Security
Policy (CSP) intended to stop many types of attacks.  The CSP header
directive relevant for stopping clickjacking is ``frame-ancestors'' ,
which specifies valid parents that may embed a page in a frame.

You can read more about the XFO attribute
\underline{\href{https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options}{here}},
and more about CSPs
\underline{\href{https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP}{here}}.

\paragraph{Modify the defender's response headers.} Open the Apache
configuration file for the defender's website
(\texttt{apache\_defender.conf} in the defender's image folder).
Uncommont the lines that specify the HTTP response headers served with
the page and substitute appropriate text in order to prevent the
clickjacking attack.  Specifically, set the X-Frame-Options (XFO) header
to the value \texttt{"DENY"} and the Content-Security-Policy (CSP)
header to contain the directive \texttt{"frame-ancestors `none' "}.

\paragraph{Hint.} Because you are making a change to the server's
configuration, you will need to rebuild and restart the containers for
the change to take effect.


\paragraph{Questions:}
\begin{enumerate}
\setcounter{enumi}{9}
    \item What is the X-Frame-Options HTTP header attribute, and why is
    it set to ``DENY'' to prevent the attack?

    \item What is the Content-Security-Policy header attribute, and why
    is it set to ``frame-ancestors `none' '' to prevent the attack?

    \item What happens when you navigate to the attacker's site
    after modifying the response headers? What do you see?
\end{enumerate}

\paragraph{Learn more.}
There are a number of other ways to perform clickjacking besides the one
explored in this lab, and many possible malicious consequences beyond
the ones suggested here. To learn more about clickjacking, visit
\href{https://owasp.org/www-community/attacks/Clickjacking}{https://owasp.org/www-community/attacks/Clickjacking}.

% *******************************************
% Submission
% ******************************************* 
\section{Submission}

\begin{quote}
\seedsubmission
\end{quote}


\end{document}
